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Abstract 

Quality attributes and constraints are among the main drivers of ar- 
chitectural decision making. The quality attributes are improved or dam- 
aged by the architectural decisions, while restrictions directly include or 
exclude parts of the architecture (for example, the logical components or 
technologies). We can determine the impact of a decision of architecture 
in software quality, or which parts of the architecture are affected by a 
constraint, but the difficult problem is whether we are respecting the qual- 
ity requirements (requirements on quality attributes) and constraints with 
all the architectural decisions made. Currently, the common practice is 
that architects use their own experience to design architectures that meet 
the quality requirements and restrictions, but at the end, especially for 
the crucial decisions, the architect has to deal with complex trade-offs be- 
tween quality attributes and juggle possible incompatibilities raised by the 
constraints. In this paper we present Quark, a computer-aided method to 
support architects in software architecture decision making. 



1 Introduction 

In the last decade, software architecture has become one of the most active re- 
search areas in software engineering. As a significant trend in this community, 
many researchers have stated that architectural decisions are the core of soft- 
ware architecture [5] . Under this view, software architecture has evolved from a 
simple structural representation to a decision-centric viewpoint .6\. Along this 
way, several methodological approaches for architecture design and analysis had 
been proposed, e.g., ADD, TOGAF, ATAM, CBAM. These heavyweight meth- 
ods offer a significant gain in the reliability of the architecture design process 
but require large-scale projects to achieve a balance between what the method 
offers and the effort that supposes for the architects to use it. This balance is 
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hard to achieve when projects are low- or medium-scale. Lighter methods that 
apply for not so large projects are required [?]■ 

In this context, we present Quark (Quality in Architectural Knowledge), a 
computer-aided method to support architects in software architecture decision 
making. This method is being implemented in a tool, called ArchiTech pQ that 
acts as a proof of concept for the Quark method. ArchiTech is already capable 
to manage AK and to reason about it in a similar way as Quark describes. 

Quark builds upon the reuse of Architectural Knowledge (AK) represented 
as an ontology called Arteon [5] . Arteon includes knowledge about architectural 
decisions, including their rationale and their link to quality attributes and con- 
straints. Among other alternatives, we have chosen to use ontologies to represent 
the AK because ontologies have been successfully used for knowledge representa- 
tion in other domains (e.g., software engineering, artificial intelligence, semantic 
web, biomedicine, etc.) and they offer other advantages such as reasoning and 
learning techniques ready to be applied (e.g., we could add new decisions using 
case-based reasoning techniques). The AK acquisition is not addressed in this 
paper, although we recognize that resolve the issues related to the acquisition 
of AK are essential to make this method useful for practitioners. 

The rest of this paper is divided in the following sections: the Quark method 
(Section^, an example of use of Quark (Section[3|), the related work (Section@|, 
and finally conclusions and future work (Section [5]). 

2 The Quark Method 

Quark aims at providing means to facilitate and making more reliable archi- 
tects' decisions with regard to quality attributes. The method starts with the 
software requirements, and ends with a set of architectural decisions and the 
overall evaluation of the quality attributes (see Figured]). The Quark method 
delivers an iterative process divided in four activities: first, specification of the 
Quality Requirements (QR) and the imposed constraints; second, inference of 
architectural decisions according to existing AK; third, decision making; and 
fourth, architectural refinement. 

The design of Quark has been driven from a critical observation gathered 
from two empirical studies we have recently conducted^: software architects 
may be receptive to new design methods as far as they still keep the control on 
the final decisions. In other words, architectural decision making should not be 
an automatic process, but just computer-aided, therefore still architect-driven. 
As a consequence, the architect plays the central role in Quark. In particular, 
there are two tasks where the architect role takes special relevance. First, in 
activity 1, the architect has to define the QR and constraints relevant to the 
software architecture. Second, in activity 3, the architect has to choose the 
architectural decisions and then decide if the decisions made are sufficient to 
end the process. In the same direction, Quark is intended to provide guidance 
but not to control the decision making process, in this sense Quark will notify 

x Not available as publication yet. 
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Figure 1: Quark overview. 



about possible incompatibilities and possible actions to resolve them, but the 
method does not require resolving detected incompatibilities to continue, the 
architect has always the last word. 

In the following subsections we describe each activity. 

2.1 Architectural Specification 

In the first activity, the architect specifies manually the QRs and constraints 
that will drive the architecture decision making. These QRs and constraints 
are the architect interpretation of the software requirements that are relevant 
for the architecture design. For example, a QR could be "performance should 
be high" (in other words, more a goal than a requirement) or something more 
concrete such as "loan processing response time should not be higher than two 
seconds 95% of the times". Examples of constraints could be "the database 
management system (DBMS) must be MySQL 5" , and "the architectural style 
must be Service-Oriented Architecture (SOA)" . In order to be computer-aided 
this specification should be formalized. We provide an example expressed as a 
Context Free Grammar (CFG) (see Figure [2]). For simplification, we included 
extra notation in the CFG: [concept] mean one valid instance of the concept in 
the Arteon ontology [2] and <symbol> mean a terminal symbol. 

Due to the Quark's iterative nature, the specification of these QRs and 
constraints does not need to be complete, which makes this method less heavy. 
The architect could start from a very short specification and then grow the 
architecture in each refinement or start from a complete specification and see if 
it matches the expected QRs, and then if necessary refine it. 
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RestrictionSet -> Restriction (LogicOp Restriction)* 
Restriction -» Action [DecisionalElement ] 
Action -* <use> | <ban> 

ConditionSet -» Condition (LogicOp Condition)* 
Condition -> ComparativeCond | ConjuntiveCond 
ComparativeCond -* [Attribute] CompOp [Value] 
Con junctiveCond -* [Attribute] ConjOp [Value]+ 
LogicOp -* <and> | <or> 

CompOp -* <greater_than> | <lower_than> | <equal_to> 
ConjOp -* <includes> | <excludes> 

Figure 2: CFG to formalize constraints. 

2.2 Decision Inference 

In the second activity, the Quark method uses the AK available to generate a list 
of decisions. Since the expected amount of decisions is large, the decisions should 
be ordered by priority criterion (e.g., the decisions that satisfy more constraints 
and better comply with the stated QRs are top priority). This criterion will be 
used in an AI local search algorithm (e.g., simulated annealing). The criterion 
can be tuned by the architect. 

Another observation from our empirical studies is that the decisions gener- 
ated need to be descriptive. For example, we could describe "data replication" 
decision as follows: "the decision is offered because there is a requirement about 
having high performance" , "by making this decision, the overall performance 
will increase but will affect negatively to the maintenance, and can damage the 
accuracy" , "also, by selecting this decision, the used DBMS is required to be able 
to operate with data replication." All this information can be obtained from 
the ontology [5] . More complete templates to describe decisions are available in 
the literature (e.g., [9]). 

2.3 Decision Making 

In the third activity, the architect decides what decisions are to be applied 
from the ones generated in the previous activity. When the architect makes a 
decision, some issues may rise. For example, there could be incompatibilities 
with previous decisions (e.g., we are selecting the "data replication" decision, 
but we already selected a DBMS that does not support data replication), or 
there could be some QRs that do not hold by the decisions made (e.g., the 
decisions indicate that maintainability will be damaged while there is a QR 
that says that maintainability is very important for this project). These issues 
may be detected using constraint satisfaction algorithms. 

As said before, the architect will be informed about which decisions are the 
most conflictive, but s/he will decide if the actual decisions are adequate or not 
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(e.g., there may be external reasons, beyond requirement satisfaction, that have 
higher priority). Also, at this point the architect has to decide if s/he wants 
to end the decision making process or make a new iteration (see refinement 
activity). 

2.4 Architectural Refinement 

In the fourth activity, the objective is to make actions that will resolve the de- 
tected issues. We identified three possible outcomes from the decision making 
activity: incompatibilities, dependencies, and suggestions for QRs. Incompat- 
ibilities were explained in activity 3. Dependencies occur when some decision 
requires the existence of other elements in the architecture. For example, when 
the architect decides to use SOA, several related decisions are needed: service 
implementation (e.g., SOAP, REST), service granularity (e.g., service composi- 
tion, single service), etc. Suggestions for QRs are inferred because some quality 
attribute is having special relevance due to the selected decisions, e.g., most of 
the decisions have positive impact on security. In that case we may suggest to 
the architect to consider including a QR about security. This help architects to 
make QRs explicit. 

The three possible outcomes are to be included in activity 1 for the next 
iteration, incompatibilities and dependencies may be translated into constraints, 
suggestions will add new QRs. Once in activity 1, the architect will decide which 
of these outcomes will be included in the next iteration and at this point, the 
architect can add or modify the previous iteration constraints and QRs. For 
example, the architect may have noticed in the last iteration that one QR was 
very difficult to meet and decide to soften it. 

3 Example 

A complete architectural decision making process is too long to be included, the 
present example will focus only in one decision, the DBMS selection. Although 
the example is centered in a decision about technologies, a similar process could 
be applied to a decision on architectural patterns. 

Following the Quark method, before starting the architect should revise 
the software requirements document of the project and identify the ones that 
are relevant to the architecture. For this example, the relevant requirements 
are: (Rl) "the software system shall keep the information about clients and 
providers" , (R2) "the software system shall be developed using OSS whenever 
possible" , and (R3) "the software system shall have high reliability" . 

3.1 Specification Activity 

Once software requirements are selected, the software architect should interpret 
them and provide the resulting QRs and constraints. From the Rl the architect 
may deduce that the project is an information system, so a DBMS will be 
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required. From R2 the architect may include a constraint on the technologies 
used to be OSS. From the R3 the architect may include constraints to have 
backup facilities, and a QR for reliability. Using the formalization presented 
in Figure [5] the specification will be: Use DBMS, "License" includes "GPL", 
"LGPL", "BSD", etc., "Backup facility" equal "yes", and "Reliability" greater 
than "average". 

3.2 Decision Inference Activity 

In this example we use as AK the information published in [5], and the priori- 
tization criterion mentioned in Section [2.2l The following possible decisions are 
generated: 

1. The decision to use MySQL 5 is offered because it is OSS. There is no 
information available about backup facilities in MySQL. MySQL is pre- 
ferred because it supports more OSS technologies. Using MySQL has 
neutral impact in reliability because ACID compliance depends on the 
configuration. 

2. The decision to use PostgreSQL 8.3 is offered because it is OSS. There is 
no information available about back-up facilities in PostgreSQL. There are 
few OSS technologies with support for PostgreSQL. Using Postgre-SQL 
improves reliability because it is ACID compliant. 

3. The decision to use SQL Server 2005 is offered because it satisfies the 
backup facility condition. SQL Server is not OSS. There are few OSS 
technologies with support for SQL Server. SQL Server will require a Win- 
dows operating system. Using SQL server improves reliability because it 
is ACID compliant. 

3.3 Decision Making Activity 

In the decision making activity, the architect, for example, will decide to use 
MySQL 5 (the decision with higher priority) as the implementing technology 
for the DBMS component. But as said before in this paper, the architect may 
prefer to use PostgreSQL, even it is not the top decision, because s/he is more 
familiar to it (or any other reason). The important point is that the architect 
is able to make informed decisions, and, eventually, new decisions that were 
unknown to her/him are taken into consideration. 

3.4 Architectural Refinement Activity 

After the decision making activity the architectural design will continue with 
new iterations, where the decision to use MySQL will impact, for example, 
in the selection of other technologies that are compatible with MySQL. This 
information will appear during the refinement activity as dependencies and in- 
compatibilities. 
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4 Related Work 



Hofmeister et al. [4] compared five software architecture design methods and 
came out with a general model of architectural design method composed of 
three activities: architectural analysis, architectural synthesis, and architectural 
evaluation. The Quark activities are not very different of these ones except for 
two differences: first, the general approach does not consider iterative methods, 
which is why we have an extra activity in our method, and second, Hofmeistcr's 
general approach deals with complete architectural solutions, while Quark works 
at decisional level. In our empirical study architects said that they will not trust 
a computer-aided method that generates full architectural solutions without 
their intervention. 

Tang et al. [5] presented AREL, a UML-based model to explore the architec- 
tural design reasoning. With this model they are able to represent the decision 
making, and it helps to share a common understanding of the rationale behind 
each decision by having well documented decisions. They also say that with 
this model they help to identify trade-offs, issues, constraints, etc. In Quark, 
we do a similar task, but thanks to the use of ontologies to manage AK and 
the formalization of the QR and constraints we are able surface these trade-offs, 
issues, constraints in a semi-automatic way with computer-aided mechanisms. 
Also, the decisions generated by Quark are well documented (as explained in 
Section |2~2|) . There is another difference between approaches, while AREL is 
thought to manage the decisions made, Quark is thought to propose decisions 
that the architect may want to make. 

There is a documentation framework for architecture decisions proposed by 
van Heesch et al. [?]. It consists of four viewpoint definitions using the con- 
ventions of ISO/IEC/IEEE 42010: a decision detail viewpoint, a decision rela- 
tionship viewpoint, a decision chronology viewpoint, and a decision stakeholder 
involvement viewpoint. The output of Quark is a set of decisions, similar to 
the first viewpoint. The other three viewpoints are not supported, because they 
refer to architectural aspects that are not representable in the ontology in which 
Quark is built upon. We do not discard to include these aspects in the future. 

5 Conclusions and Future Work 

In this paper we have presented the Quark method, a method to support archi- 
tects in software architecture decision making. The key features of this method 
are: 

Computer-aided: Quark facilitates some parts of the decision making pro- 
cess, principally: the generation of a priority list of decisions and the detection 
of incompatibilities. 

Lightweight: Quark guides the architect in the decision making by giving 
suggestions and indications, with this we expect to reduce the time to design 
the architecture. 

Flexibility: Quark may start just with few QRs and constraints or with a 
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full specification. 

Ontology-based: Quark is built upon an ontology. Ontologies are well known 
in AI, and there are techniques ready to be applied for the reasoning with 
knowledge that is represented using ontologies. 

Complement architects' knowledge: The reuse of AK may help to comple- 
ment architects' knowledge, e.g., the architect may not know all the effects of 
using a technology or an architectural pattern, it may need of other components 
to work correctly or it may have unexpected effects on the evaluation of some 
quality attributes. 

Future actions with regard to this method include: finish the ArchiTcch 
tool [T] that serves as a proof of concept of this method. Next, use the method 
in a real project as a validation strategy (we are in collaboration with one 
software company, Everis, that may fit to this end), and then include it in our 
envisioned framework using Model-Driven Development techniques [3J. 

There are two limitations in Quark that need to be adjusted: first, Quark is 
thought to be used at the beginning of a project as the initial decision making, it 
would be more useful if the method could be used during the whole development 
time, and second, Quark only deals with the structural parts of the architecture 
(e.g., patterns, styles, technologies, etc.) other aspects need to be supported as 
mentioned in Section 2] 

Finally, issues related to AK acquisition, AK maintenance, and AK reusabil- 
ity should have more attention from the architecture community because these 
topics are crucial to make this and other approaches suitable for practitioners. 
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